home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Collections: MegaDisc
/
MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].zip
/
MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].adf
/
ARTICLES
/
multitasking
< prev
next >
Wrap
Text File
|
1988-05-28
|
17KB
|
303 lines
MULTITASKING AND THE AMIGA
by Peter McKellar
[Ed: Peter is a Consultant Systems Programmer in large IBM mainframe
environments. He's also put together a MultiTasking Theme Disk
pulling together material from various sources on this very
important topic, including Pete Goodeve's IPC standards - see the
end of the article. Many thanks, Pete.]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
People are often confused by the term "multitasking". This article will
attempt to explain some terms for the novice. If you are an experienced
user there may also be a few points for you.
Multitasking Comparison.
It doesn't take a genius to see that the Amiga is a far superior machine
to an IBM PC or clone. We all know that an Amiga is better than a MAC or
ATARI, both on price and performance. But what is it that makes the Amiga
really shine? Obviously, its multitasking capability alone makes it stand
out from the opposition. PC users claim that "MEMORY RESIDENT" programs
permit them to run more than one thing at a time. MAC users also claim
that their machines permit more than one program to run at a time. The
ATARI user, whilst closest of all, claims multiple execution is possible.
This is not true. Multitasking, in the full meaning of the word, does not
occur.
None of these others can boast the power of the Amiga's true multitasking
environment. The term, "memory resident", simply means that a program has
been preloaded into memory. This means that it is occupying memory, lying
dormant until branched to by a key-stroke. When this occurs the previously
executing program loses control until another key-stroke combination is
used. An apt analogy would be to a large program with procedures that are
branched to when certain keys are hit. The only difference is that various
parts of the program are sold by different suppliers. Memory management
becomes a problem when so many users want to share only 640K. All the pro-
grammers must agree upon where their code will reside. The unfortunate
truth is that most suppliers don't. System crashes result when programs
don't agree. You often see suppliers giving the cryptic instructions:
"LOAD ME LAST"
The basis for this is to ensure that memory doesn't get corrupted and that
branch vectors are installed correctly.
The MAC also relinquishes control of the CPU to another task when the user
"clicks" on another icon, thereby selecting it for execution. Everything
else stops while the currently active task takes over, even if this task
is awaiting input from the keyboard or serial port, or patiently sitting
back while your slow old printer grinds out another line or two from the
buffer.
The ATARI is similar to the AMIGA in that multiple tasks can coexist and it
does share some of the CPU cycles throughout different functions. This is
done on a fixed time, rotational, basis. But tasks don't have a priority
based scheduling system like the AMIGA. I haven't undertaken a study of
the ATARI, but I believe that the AMIGA supports a far more extensive lot
of operating system calls. I can't deny it - I'm just an AMIGA BIGOT!!!
In theory, the new OS/2 system, for IBM PCs does offer some sophisticated
multitasking capabilities. But let's face it, there isn't any software
around that uses any of the features. It costs a fortune and won't run on
less than one and a half meg. That's the first release of OS/2, the full
blown version, with graphics and all, will require 4 megabytes - just for
the operating system (pretty hot, eh?). The full-featured version is not
yet available. It's actually tied up in litigation from APPLE, and nobody
is writing software for it until the court case is decided. As the case is
simply a stalling action brought by APPLE, to cripple IBM's release of
OS/2, it could possibly be dragged on for years. In the meantime, this
is an opportunity for the AMIGA to slip through and top sales over both.
The AMIGA operating system is far superior to all of the systems now avail-
able. Its system displays the same techniques of multitasking that can be
seen on high-end work stations right through to large mainframes. The only
real difference lies in the ability to recover from catastrophic errors.
The AMIGA Operating System is likely to invoke Mr. Guru if you don't follow
the rules properly.
MULTITASKING OVERVIEW.
As microprocessors become faster and faster, multitasking becomes more and
more important. Even with the superb custom chips installed in the AMIGA,
I/O speed is a major contraint. It is wasteful for the CPU to be idle as
it waits for input or output operations to complete. Any service that
relies on some physical action (eg driving the electron guns that display
text and graphics on the screen, or reading a disk) takes thousands of
times longer to complete than the execution of programs within the CPU.
It even takes longer to execute instructions that operate on RAM, rather
than the data registers located on the microprocessor chip.
Multitasking allows the processor to INITIATE one of these time-consuming
activities (eg write to the disk) then promptly forget about it. It can
now move on to more productive activities, like playing a game, calculating
pi to a million places, compiling a program, balancing your accounts and
any other tasks that require your attention and computing power. Each
time one of these other tasks no longer requires CPU cycles, someone else
gets a chance to use the processor. More important tasks may also gain
access to the CPU by forcing an interrupt.
But how does the Operating System achieve such harmony, such a blissful
and orderly sharing of resources? By careful design and hardware support.
Commodore have a priority-based task dispatching technique. This is
possible only if the software is well written and documented so the user
(in this case, the programmer) can access required services (eg, read).
The hardware must also permit interrupts, which stop the currently active
task and allow the Operating System to reassign control of the CPU to a
more deserving task. The ability to interrupt a task makes this a
"pre-emptive" Operating System.
Only a task with a higher priority than the currently executing task can
usurp control from the present task. Tasks in the system with the same
priority as that currently executing will still get to use the processor.
Tasks of the SAME priority get to equally share CPU on a rotational basis.
The operating system forces a time interval interrupt to ensure that one
task doesn't hog the chip.
If it wasn't for multitasking, the CPU would be idle for the greater part
of its existence. Multitasking allows the user to regain most of the power
otherwise lost. When higher priority tasks are waiting for resources other
than CPU, lower priority tasks can execute. They will be interrupted and
put on hold by those higher priority tasks when their wait condition is no
longer outstanding (eg their I/O has completed). When the higher priority
task again waits, the lower priority task again gains control. The same
happens time and time again.
INTERRUPTS.
The term "interrupt" has been mentioned several times so far. Maybe I need
to clarify just what an interrupt is, and how they work. Interrupts are
first supported in the hardware of the Motorola 68000 microprocessor chip.
The 68000 recognises any number of interrupts, but only seven priority
levels are recognised. Priority becomes important when multiple interrupts
are in effect. An example of when this will occur is when an interrupt is
received from an external device (say a disk drive indicating it is ready
to transmit data) and a program has tried to do a divide by zero. The
system must be able to distinguish who to service first, the program or the
drive. The Amiga's Operating System provides further discrimination with
interrupts. In conjuction with the Peripheral Interface Adapter chip, (the
8520), and one of the custom chips, the 4703, up to 16 interrupt levels are
provided. The table below shows these.
4703 CPU Pseudo
Name Priority Priority Purpose
NMI 7 15 Non-Maskable Interrupt
INTEN 6 14 Special (Copper)
EXTERN 6 13 8520B, external level 6
DSKSYNC 5 12 Disk Byte
RBF 5 11 Serial Input
AUD1 4 10 Audio Channel 1
AUD3 4 9 Audio Channel 3
AUD0 4 8 Audio Channel 0
AUD2 4 7 Audio Channel 2
BLIT 3 6 Blitter Done
VERTB 3 5 Vertical Blank
COPER 3 4 Copper
PORTS 2 3 8520A, external level 2
TBE 1 2 Serial Output
DSKBLK 1 1 Disk Block Done
SOFTINT 1 0 Software Interrupts
In our example, the standard CPU's seven priorities could have resolved the
conflict. A DSKSYNC would have been received at priority "5" and the zero
divide would have generated a level 1 priority interrupt, ie SOFTINT. But
what if the COPPER and the BLITTER both generated an interrupt during a
vertical blanking period interrupt? Purists would recognise that this is
an improbable, if not impossible situation, but serves only as an example.
It does however demonstrate the neccessity of the extended interrupt
priorities provided by the AMIGA's Operating System.
DISPATCHING.
Now that we realise what the custom chip's role is in assigning priorities,
who will get dispatched first ? A task can be in one of 6 states , they
are :
1. Running
2. Ready for execution
3. Waiting on an external event
4. Just added to the ready queue
5. Being removed from the Task queue
6. Awaiting special exception processing
Items 4,5 and 6 are transient states and will not be discussed , The system
maintains 2 queues of tasks that are not presently running. The first is
sorted on priority and contains "ready tasks", those available to be
dispatched.
The second queue is a list of all tasks awaiting an external event (eg the
completion of I/0). These are not held in priority order. When an
interrupt is generated (for example,when the I/O completes to a device),
the queues are re-examined. The task that was on the "not ready" queue,
but whose I/O just completed, is requeued onto the "ready tasks" queue.
This queue is then scanned from the head of the queue. As this queue is
sorted into priority order, the highest priority task will be found first.
This will be dispatched. The exception to this comes when a pre-specified
"quantum" of time has expired. When this happens, the next task of the
same priority gets a chance to execute. This time-slicing will continue,
amongst the highest priority tasks, until a higher priority task is
placed at the head of the "ready tasks" queue.
Priorities can range between -128 (the lowest) to +127 (the highest).
System tasks vary between -20 and +20. Zero priority should be used by
user applications unless a special interaction with system tasks is
required.
USING MULTITASKING
Multitasking can fall into one of 3 broad catergories.
1. Stand alone processes
2. Processes generated by another process
3. Tasks generated by processes or other tasks
STAND ALONE PROCESSES are what you generate if you run a batch file or
command under CLI, or cause another window to be opened under WORKBENCH.
A more common example would be having a clock active in your title bar,
doing a background print of a file, and doing a directory list to your
console. This serialization of resouces may also require the program to
wait (eg wait for keyboard input, letter by letter, of a command). More
waits will occur if both your directory listing, and your file print, need
to use the disk drive at the same time. This is a far more efficient way
to use your machine than if you were to do each task in turn. The actual
elapsed time will be much less - who says there's no such thing as a free
lunch? I guess the only real cost is in CPU cycles required to service
the dispatching cycle, maintaining the queues, and serializing access to
physical devices like the disk drives. These are all pretty meager costs
compared to the savings.
The more observant readers will have noticed that I used two terms before,
TASK and PROCESS. These are both features of multitasking but they work
at different levels of the operating system. Tasks work at a much lower
level that Processes.
Tasks are unable to perform DOS functions (eg producing output) and so a
process may have to spawn another process if these facilities are required.
The difference lies with a process being created through DOS, whereas a task
is one level lower, being created by EXEC. Consequently, if you want a
technical reference for setting up a Process, you refer to the AmigaDOS
Manual, put out by BANTAM. The section of this manual titled "AmigaDOS
Developer's Manual" (bottom of page 189 in my copy) will show you the
syntax of a "LoadSeg" call, over the page is the "UnLoadSeg" call. These
calls load and unload segments of code for the express purpose of
spawning new Processes. The address of the code just loaded is referred
to in the "CreateProc" call (page 187).
Tasks are explained in the "ROM Kernel Reference Manual: Exec". The two
calls AddTask and RemTask are used to create tasks at the Exec level. The
calls rely on the correct initialization being performed. All necessary
information can be found in the Exec manual, and this is illustrated with
many examples. But if you're the lazy type like me, this won't be
sufficient. I NEED code, in machine readable format (ie on disk), and I
have to know that it works. For this reason I have scoured the FISH disks
and found some interesting material. Megadisc Theme disks are currently
in preparation, specifically demonstrating task and process creation.
Existing public domain offerrings are possibly a little cryptic, and don't
always deliver what they promise. I will be reworking these into a format
suitable for distribution and append relevant documentation. Megadisc will
notify its readers when the disks become available.
Follow-on articles will provide relevant code, comprehensively annotated,
so that you too can write multitasking programs!!
IPC
On a slightly different track, I have just received word from Pete Goodeve
(of XICON fame) in the USA. He has been the leading light and inspiration
for a new standard - "IPC". This new and mysterious acronym is short for
"Inter Process Communication". This standard will do for multitasking what
IFF did for files. The standard will permit different modules to talk a
common language provided that all agree to follow the same conventions.
But, you ask, why? The possibilities are limitless. It would be possible
to mix'n'match commercial packages and public domain software. The word
processor of choice with your favourite spelling checker, a different
printing package, and then send it all by modem to a friend - but all by
the one program. External interfaces with a database retrieval system
could be all powerful. Real time data capture by slave processes would
be simple, your comms package could quietly lift data off a videotex
system, pass it to one of a number of slave processes, depending on
content. Key values could be plugged into your spreadsheet: - by now
you're starting to see the awesome power of such a standard??!!
Pete and his co-workers had posted this standard on USENET in the USA and
after much debate its form has stabilised. The very first copy of the
sample disk arrived in my letterbox only days ago, along with three
catalogues and two bills. No doubt you'll only be interested in the
sample disk, so I've forwarded this to Megadisc, for packaging as a theme
disk.
If sufficient interest is shown, I will write some more on the standard in
a future issue of Megadisc. I suspect that we will hear far more about
this new standard in the coming months.
[Ed: Any programmer out there who is interested in this IPC development
and wants to get Pete's disk, just call on (02) 9593692. This initiative
looks like it could out-hype HyperCard on the Mac, but like anything that
starts, it needs support, especially from other countries. So anyone who
needs a project, here it is. And Pete Goodeve is a most deserving person,
not to mention capable - a bit of gossip, he tells me that WorkBench 1.3
featured a XICON lookalike, with no attribution to him. After presenting
his case to Commodore, they decided to change the name to ICONX...And
anyway, it doesn't work on the 1.3 currently available. Anyway we
continue to use the excellent XICON and are grateful to Pete for the
support he showed from the very beginning.]
XXXXXXXXXXXXXXXXXXXXXXXXXXXX END OF MULTI-TASKING XXXXXXXXXXXXXXXXXXXXXXXXX